The approaches described in this section could be pursued, but are not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, the approaches described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section.
Enterprise network management is undergoing an architectural shift from solutions based on single servers to solutions based on distributed appliances and applications. Future network management solutions are expected to comprise a management network consisting collaborative appliances and management servers. Security for such a management network will be a critical factor.
Security in the management domain translates to providing management stations with authentication, authorization and accounting (“AAA”) services. Further, there is a need to provide strong security for communication links among the management stations. This need includes strong security for web access to a management station, strong security for inter-station communication and strong security for communication among management stations and devices.
Authentication, authorization, and accounting servers (“AAA servers”) are widely d for authorizing use of network devices, such as routers, switches, gateways, and others. FIG. 1A is a block diagram illustrating a simplified network arrangement in which an AAA server is used. A user 102 is associated with a terminal 104 or other host that hosts a network management system 105A. The terminal 104 is communicatively coupled to a network 106, which may be a local network, wide area network, or one or more internetworks.
An AAA server 120 also is communicatively coupled to the network 106. A commercial example of AAA server 120 is CiscoSecure for UNIX, Cisco Access Control Server (ACS), and Cisco Access Registrar, all offered by Cisco Systems, Inc., San Jose, Calif. A network management server 105B may process requests received from network management system 105A, which is a client of the server 105B.
Network management products have had role-based access control (RBAC) authorization frameworks that work independent of device authorization mechanisms like RADIUS and TACACS+. As a result, enterprises that have deployed both an AAA server and a network management system have had to use separate servers to define authorization policy. For example, a TACACS+server is used for device authorization, and the network management application server is used for application authorization. This is undesirable because it is not unified; the approach requires an enterprise to deploy separate authorization policies on each server. These policies may conflict, or personnel may fail to establish the same policy on each server. Further, it is desirable to have a single point of administration for both application and device authorization policy.
An additional problem with this approach is that an application cannot determine, in a simple way, whether a user is authorized to perform a set of commands across multiple devices, such as devices in an authorization group. There is a need for an approach that is more scalable and can permit determining authorization for numerous commands across numerous devices in a single transaction.
There is a need to have a single point of administration for device command administration as well as application authorization.
In particular, there is a need for a way to provide application authorization in addition to the device authorization in the context of a network with an AAA server. It would be desirable to provide a solution to these problems within the context of existing authorization protocols.
One or more network devices 108 are within the network 106 or connected to the network. Each such network device 108 hosts an operating system 112 that includes or hosts, among other elements, an agent 110. The network device 108 is identified by a Media Access Control (MAC) address 108A and an Internet Protocol (IP) address 108B. The AAA server can communicate with network device 108 and other elements using a messaging protocol tailored for AAA functions, such as RADIUS or TACACS+. Functions of operating system 112 and device 108 are accessible using terminal 104 using a command-line interface (CLI) provided by the operating system.
To illustrate conventional operation of a system having this arrangement, assume that user 102 wishes to configure network device 108 in a particular way by executing a CLI configuration command on the device. The user 102 establishes a connection of terminal 104 to a management interface of device 108. The user 102 enters the desired CLI command. In response, agent 110 issues a request, typically in the form of a message that conforms to RADIUS or TACACS+, that requests AAA server 120 to determine whether the user is authorized to perform the requested command on the device. The message identifies the user and requested command. The message also implicitly identifies the device in that the source IP address of the message is the device IP address 108B. Based on the source IP address, user identifier, and requested command, AAA server 120 determines whether authorization is proper, and issues either a Success or Fail response message. If the response is Success, device 108 executes the requested command.
In current implementations of TACACS+, an authorization request issued by a device has the following general format:                user = <user issuing the command>        service=shell        cmd=cmd1                    cmd-arg*cmd1-arg1            cmd-arg*cmd1-arg2wherein “user” identifies a user who is issuing a command to a device, “service” has the value “shell” to identify a terminal shell interface, “cmd1” is a command of a command-line interface of a network device operating system, and “cmd1-arg1” and “cmd1-arg2” are first and second arguments of the command. However, using such a request, a device can authorize only one command at one time. Further, implicitly there is only one device against the authorization can be checked. Network management applications now require the ability to support multiplicity, i.e., a single authorization request should be able to support authorization multiple devices and multiple permissions.                        
Thus, in past approaches, a network device has issued the request for authorizing execution of a command on the device by a particular user. There has been no way for an application, such as network management system 105, to request authorization from an AAA server for execution of a particular command on a device by a user of the application.